Software development is a rapidly-changing field that's moving faster than ever. Historically, software has been built in a “Waterfall” way, meaning that software products are defined, developed, tested, released and maintained in sequential order. The Waterfall days have essentially ended because the pace of technology innovation and business continue to accelerate, so developers have less time than ever to get a product or product upgrade to market.
The environment in which software runs has become more complex. Decades ago, there were few operating systems and not many PC manufacturers. Now, many companies are building laptops, tablets, phones, and other everyday products that have computing capabilities. Those devices run on a myriad of networks and communicate with each other across those networks. As consumers, we don't care about all the technical details that make up the environment in which the software we use runs, we just want to do what we want, when we want to do it.
The faster product cycles and increased environmental complexity have forced software teams to adopt new ways of working. The new work styles ensure that better quality products can be delivered faster.
For the last couple of decades, increasing numbers of software teams have become “Agile.” Essentially, Agile methodologies enable software teams to deliver better quality software faster. To do that, they break down what used to be huge software programs into much smaller parts. While it might seem counterintuitive, Agile teams can actually accomplish more in less time than Waterfall teams.
The reason Agile methods enable faster delivery of better quality software is because small pieces have smaller setbacks and larger pieces have larger setbacks. For example, companies have spent a year or two building software products that cost millions of dollars only to discover that it doesn't align with a market requirement or the software quality is poor.
By doing small things rapidly, Agile teams can “fail fast” and fix their mistakes as they go. Agile teams also benefit from a constant customer feedback loop which allows them to manage their time and budgets more effectively. Another characteristic of Agile teams is that they're cross-functional. Rather than doing their specific jobs and not really communicating with other functions (which is typical of Waterfall practices), they're working together to set priorities and remove inefficiencies from their processes.
“DevOps” combines software development and operations. The trend started to gain momentum in the early 2000's because there were often disconnects between how a developer thinks the software he's building will operate in the real world and how that software actually works in the real-world.
Developers and operations teams don't naturally come together, however. They have to agree to cooperatively embrace DevOps. Historically, the two groups have had a contentious relationship because developers want access to “production” systems so they understand how their software will behave in the real world. However, operations do not want to give developers access to production systems because their business runs on them. One simple misconfiguration could cause all or part of a business to be “shut down.”
To solve this problem, some vendors built software tools that allow developers to emulate production systems, but real and fictional environments tend to differ. Cloud computing helps to resolve the differences because actual and test systems can be configured more identically. (Basically, a “cloud” is a massive compute and storage environment that businesses can rent on a usage basis. Slowly, but surely, businesses across industries are moving to the cloud because they're finding it very difficult if not impossible to continue building and maintaining their own information technology (IT) infrastructures in today's fast-changing business world).
Clouds are increasingly important to software development, because more and more applications are running in clouds, such as mobile phone applications, Facebook, Google, and Amazon.
Continuous delivery is a software development method that builds upon the concepts associated with both Agile and DevOps. Continuous delivery works faster than either Agile or DevOps can on their own. It's necessary, because software delivery cycles are continuing to shrink. There are several reasons why the cycles are shrinking including the two biggest factors; customer expectations and disruptive companies that have always operated online or in the cloud (“digital natives”).
The most progressive software companies are increasing employing continuous delivery, if not continuous deployment, which moves at an even faster pace. These companies aren't delivering software once a year, once a quarter or even once a month. They're releasing software weekly, daily, or in most cases, several times per day. How often a company releases software really depends on its business model and its customers' expectations. However, they are all under pressure to deliver software faster.
This acceleration and speed at which software development is occurring is associated with an increased loss of securitization.
When it takes software a year or two to go from concept to product delivery, there's more time for quality and security related testing. As software cycles diminish, there is less time for quality and security checks. Shortcuts and oversights can be devastating. For example, the Equifax breach discovered in 2017 was the result of failing to update (“patch”) certain open source software in a timely manner. The patch had been available for the six months leading up to the breach. Had Equifax installed the patch, that particular hacking incident wouldn't have occurred when it did or perhaps not at all.
Hackers and software “pirates” expect software developers to make mistakes and take shortcuts. They also expect to find holes in software testing, and they are betting on the fact that even security experts don't understand all the vulnerabilities. Given the amount of software that powers our modern world and the increasing speed at which that software is being developed, security breaches will continue to occur. Unfortunately, security breaches are becoming increasingly common and increasingly severe.
The present disclosure was developed so that software developers can secure the products they're building without spending any extra time, which makes it ideal for Agile and DevOps teams whether they're performing Continuous Delivery or not. If they want their software or device to communicate with any other piece of software or device securely, the present disclosure addresses this need.
Given the pervasive nature of software today, companies and individuals are constantly at risk. Although it's not apparent to most people, software runs almost everything you can think of from manufacturing floors to airplanes, cars, TVs and children's toys. All of the software developers, and the organizations for which they work, are responsible for the quality of the software they're building. Security is a critical part of quality, and it's becoming increasingly important.
Software containers are a solution to the problem of how to get software to run reliably when moved from one computing environment to another. These containers can be utilized for example for anything including a software developer's laptop to a test environment, from a staging environment into production, as well as from a physical machine in a data center to a virtual machine in a private or public cloud.
Problems arise when one or more supporting software environments are not identical. For example if a software developer or architect is going to test using Python 2.7, (Python is an interpreted, object-oriented programming language similar to PERL, that has gained popularity because of its clear syntax and readability) and then run the executable program on Python 3 in production, there is a degree of probability that something unexpected will occur. Another issue that may arise, is if the developer relies on the behavior of a certain version of an SSL library (SSL is a programming library that secures communications. SSL is a standard way of establishing communication between two devices over a network where others could be “listening in” on the conversation) but another one is installed instead. The developer could perform testing on Debian (Debian is a Unix-like computer operating system that is composed entirely of free software, most of which is under the GNU General Public License and packaged by a group of individuals participating in the Debian Project). and production is performed using a Red Hat operating system. Again, the results could be and often lead to unexpected/unintended consequences. These issues are not confined to software malfunctions but network topology might not match and/or the security policies and storage might be different. In all cases, however the software still has to perform properly and as initially intended.
Software containers are utilized to solve these issues. Put simply, a container consists of an entire runtime environment: an application, plus all its dependencies, libraries and other binaries, and configuration files needed to run (execute) it, bundled into one package. By containerizing the application platform and its dependencies, differences in OS (operating system) distributions and underlying infrastructure are abstracted away.
There is a difference between containers and virtualization technology. With virtualization technology, the package that can be passed around is a virtual machine, and it includes an entire operating system as well as the application. A physical server running three virtual machines would have a hypervisor and three separate operating systems running on top of it.
By contrast, a server running three containerized applications using software containers runs a single operating system, and each container shares the operating system kernel with the other software containers. Shared parts of the (OS) operating system are read only, while each software container has its own mount (i.e., a way to access the container) for writing. That means the software containers are much more lightweight and use far fewer resources than virtual machines.
Other benefits of implementing software containers includes the fact that a container may be only tens of megabytes in size, whereas a virtual machine with its own entire operating system may be several gigabytes in size. In this instance, a single server can host far more containers than virtual machines.
Another major benefit is that virtual machines may take several minutes to boot up their operating systems and begin running the applications they host, while containerized applications can be started almost instantly. This means that software containers can be instantiated in a “just in time” fashion when they are needed and can disappear when they are no longer required, freeing up resources on their hosts.
A third benefit is that containerization allows for greater modularity. Rather than run an entire complex application inside a single software container, the application can be split into processor s (such as the database, the application front end, etc.). This is the so-called “microservices approach”. Applications built and provided in this manner are easier to manage because each processor is relatively simple, and changes can be made to processor s without having to rebuild the entire application. Because software containers are so lightweight, individual processors (or microservices) can be instantiated only when they are needed and are available almost immediately.
A company known as “Docker” has become synonymous with software container technology because it has been the most successful at popularizing it. However, software container technology is not new; it has been built into Linux operating systems in the form of LXC for over 10 years, and similar operating system level virtualization has also been offered by FreeBSD jails, AIX Workload Partitions and Solaris Containers.
Standardization of software containers began in earnest in 2015, with another company known as CoreOS, which produced its own App Container Image (ACI) specification that was different from Docker's container specification, and at the time there was a risk that the newly-popular container movement would fragment with rival Linux container formats.
However, later in the same year, an initiative known as the “Open Container Project” was announced, and later renamed as the Open Container Initiative (OCI). Run under the auspices of the Linux Foundation, the purpose of the OCI is to develop industry standards for a container format and container runtime software for all platforms. The starting point of the OCP standards was Docker technology, and Docker donated about 5 percent of its codebase to the project to get started. Additional project sponsors include; AWS, Google, IBM, HP, Microsoft, VMware, Red Hat, Oracle, Twitter, and HP as well as Docker and CoreOS
The idea of the OCI is to ensure that the fundamental building blocks of software container technology (such as the container format) are standardized so that all software developers and architects can take advantage of them. This initiative would then provide the ability to reduce spending resources developing competing software container technologies so that organizations can focus on developing the additional software needed to support the use of standardized software containers in an enterprise or cloud environment. The type of software needed includes
A major concern and major objective of the present disclosure involves the fact that many people believe that software containers are less secure than virtual machines. This is due, in part, to the possibility that if there is a vulnerability in the container host kernel, this vulnerability can provide a way into the software containers that share the host kernel. This issue is also true for a hypervisor. A hypervisor is a virtual machine monitor (VMM) that is computer software, firmware or hardware that creates and runs virtual machines. A computer on which a hypervisor runs one or more virtual machines is called a host machine, and each virtual machine is called a guest machine. However, because a hypervisor provides far less functionality than a Linux kernel (which typically implements file systems, networking, application process controls and so on) it presents a much smaller attack “surface” for a virus to be implanted or to access sensitive data. In the last couple few years a great deal of effort has been devoted to developing software to enhance the security of containers. For example, Docker (and other container systems) now include a signing infrastructure allowing administrators to sign container images to prevent untrusted containers from being deployed.
However, it is not necessarily the case that a trusted, signed container is secure to run, because vulnerabilities may be discovered in some of the software in the container after it has been signed. For that reason, Docker and others offer container security scanning solutions that can notify administrators if any container images have vulnerabilities that could be exploited.
More specialized container security software has also been developed. For example, Twistlock offers software that profiles a container's expected behavior and “whitelists” processes, networking activities (such as source and destination IP addresses and ports) and even certain storage practices so that any malicious or unexpected behavior can be flagged.
Another specialist container security company known as Polyverse takes a different approach. It takes advantage of the fact that containers can be started in a fraction of a second to relaunch containerized applications in a known “good” state every few seconds to minimize the time that a hacker has to exploit an application running in a software container.
Using the devices and techniques of the present disclosure, developers can start securing their applications within a relatively short period of time. They won't have to configure anything or know anything about security for the system to properly operate. Developers can simply wrap their application up in a software container which is like placing personal items in a portable storage container that's under lock and key.
However, unlike storage containers, the software containers of the present disclosure are able to communicate with each other securely via an encrypted link.
The present disclosure provides software developers with a new and better way to secure whatever software they're building so when that software communicates with either a copy of itself or other types of software, including the software resident in various types of devices, the data is kept safe. More specifically, the present disclosure describes the use of the first known context-free and natively-secure software containers that enable software developers the ability to take ownership of application data security. Context free means that developers do not have to rely on a particular vendor/platform (i.e. Amazon, IBM, Cisco, etc.) and is independent of the type of container used. These devices and system are “natively secure” in that they are built into the actual structure of the container itself. Securitization and encryption occurs at the transport layer such that the application developers are writing applications that create connections to the rest of the communications world at the transport layer. In this manner, the application developers/writers who create the applications can take ownership of the security themselves instead of handing it off to someone else in the operation or to some external router. Developers using the system disclosed are now in full control of security in that the developer is specifying the data security and the data security is being supplied to their application as they determine and as they complete their task(s). Companies developing software applications such as Layer 3 (Norcross, Ga.) and Technologent (Irvine, Calif.) are anxious to deploy this new development. They see the system as the ability to offer a ubiquitous capability to provide security for specific platforms. Utilizing the devices and system of the present disclosure, any developer can secure communication between software containers across disparate scheduling and orchestration platforms, IaaS (internet as a service) services, transport-layer security protocols, and on-premises or hybrid environments using Docker-compatible hypervisors. Such hybrid IT environments include colocation (hypervisor) and AWS ECS.
This system provides DevOps teams with a method to build, deploy and run secure container applications without the costs associated with legacy security strategies.
Using software containers will also become more ubiquitous due to the new securitization techniques disclosed herein because the legacy security strategies will either use an appliance (routers, servers, etc.) which will contain the presently disclosed security system or because legacy security can be improved by running a small program (software routine) that can be included with (added to running on) the actual legacy equipment. This small program is a symmetric TLS library (currently written in Python) that encrypts and decrypts egress and ingress layer 4 traffic (respectfully) using configurable symmetric encryption TLS cipher suites. This program is often embedded (the code) into the container. The library is 2.5 times faster than the most used open source python crypto wrapper, meaning that cross-platform networks can now be effectively secured without suffering unacceptable latencies.
Further description of layer 4 traffic is provided below. This software routine can be installed on another piece of computer equipment and is both the library and the intercept of the present disclosure added in the form of a software router.
Currently, legacy systems are supposed to provide secure communications via IP SEC- or IP security. IP security is a layer 3 protocol that supplies secure channels/tunnels between IP addresses. In this case, tunnels themselves may carry signals that may include channels and tunnels may carry channels or tunnels may carry signals through other tunnels. Here, a data channel is an information route with associated circuitry that passes data between systems or parts of systems. Tunnels in this case also refers to tunneling and is a mechanism used to ship a foreign protocol across a network that normally would not support that protocol. In either case, a tunnel can be used to penetrate through obstructions (such as firewalls that would be otherwise impenetrable) where channels may not provide this feature. A significant issue that the present disclosure addresses includes the fact that IP SEC is a difficult to configure and a difficult to keep operating software that is normally inserted into an appliance. There is also difficulty with operating IP SEC as there is a limited amount of encryption security using the standards available. The cost of IP SEC is also relatively high and normally provided by very few vendors including CISCO. IP SEC normally involves scheduling and orchestration platforms—this is for network servers and is a form of load balancing that requires computer resource scheduling. Orchestration involves the location where the code (in this case the security code) is being executed. To date, inter-container communications have not been addressed adequately by existing container orchestration frameworks and protocols. ICEMicro changes that by providing developers with a natively secure container image to package application code. Since secure communications are an inherent feature, any two ICEMicro containers can communicate securely “out of the box.”
Another significant issue is the disparity caused when different network resources operate on different companies' clouds, often causing extreme communication mishaps. Currently the solution has been that disparate regions also function on different clouds (e.g. Amazon UK vs Amazon, USA) and a current method to get these two disparate entities to communicate with each other is to get another resource from Amazon for both ends and pay for a bridge between one application on Amazon US to one or more applications with Amazon UK. This requires adding another virtual device that has to run on the Amazon platform. Either Amazon provides this service or you pay Cisco for their Virtual Router. Another possibility is that the developers must write the code themselves which becomes embedded on both ends. In this last instance, the developer must now manage their own communication security has to develop new code. Normally, no developer wants to purchase Cisco's IP SEC or use Amazon's or some other software equivalent. Today Cisco and its affiliates utilize a software version of IP SEC which is encrypted and Amazon and others do not have this security application. In short, developers are utilizing hybrids that may or may not provide the security they think they are applying to newly developed software using software containers.
In contrast, the present disclosure utilizes a level 4 securitization technique for TLS (transport layer security). Level 4 refers to layers that are in a communications stack which from bottom to top is as follows:
Communication Layer (1): Wires and connectors
Communication Layer (2): Software running over Layer 1—such as token ring or ethernet
Communication Layer (3): Wireless area networks—if wireless connecting from one computer or other hardware device to another IP address—such as the internet—IP address to IP address communications.
Communication Layer (4): As communications go through the stack from top to bottom, where the manner of transport is irrelevant this last layer becomes the security layer, which presently is where IP SEC resides and is executed.
This “Layer 4” is known as the transport layer security level or TLS—where security is occurring at the transport layer. Here is where the communications “traffic” is routing from or to communications ports. Typically layer 4 is attached to the application itself and provides logical connections between applications. This, understandably is why TLS security is critical. The present disclosure describes devices and systems that places the TLS security into the structure of the container itself. In this manner, a developer can provide any application immediate security within the container using the “ICEMicro security devices and systems”. The system allows the developer to inform the container(s) what connections are allowed between transport layer(s) and where the “ICEMicro” securitization and/or encryption should be placed. This technique creates and provides a “tunnel” that now exists from one container to a different container and utilizes its own dynamic key and with its own tunnel. The ICE system may provide multiple tunnels as there are 16 bits of tunnels which equates to 65,535 ports, all of which can possess their own keys. The keys are dynamically changed by the “ICE” Library. In addition, each tunnel can go to any other location (including other containers), all capable of running individual independent sets of security on their data transmissions. Developers will gain significant speed and efficiency using the “ICE” system, as securing communications between two containers is accomplished as quickly as applications can be created. ICEMicro does not require additional development overhead or network security expertise.
Presently, developers who use TLS security don't get this level of security from other platforms provided by other vendors. Unlike most current strategies, ICEMicro does not depend on the transport layer for data security. However, it is compatible with any transport layer security protocol. Transport layer security protocol vulnerabilities are well known. As quickly as protocol upgrades are deployed, hackers exploit new vulnerabilities. Networks deploying legacy TLS pose even higher risks. ICEMicro is agnostic to the TLS protocol and natively secures the communications between containers within legacy or greenfield environments, limiting successful TLS hacks access to encrypted data only. Essentially, ICEMicro renders TLS unnecessary.
The devices and system of the present disclosure utilize running dynamic ephemeral (temporary) keys as another layer of protection provided by the encryption tools (also described herewithin). The present disclosure describes an “ICEMicro” version of a TLS protocol, which can be run on/or embedded in containers (or hybrid systems). In addition, the present disclosure supports container compatible Hypervisors. Hypervisors are layers of software located between the actual computer systems and the operating systems—which enables virtual operating systems and controls instruction sets to operate on the same computing platforms developers utilize during software development. In addition, the Hypervisor translates the capabilities of some hardware into a portion of a standardized virtual hardware and controls the access to that virtual hardware.
The ICEMicro devices and system of the present disclosure provides security bridges to containers directly with built-in security DASA encryption. These are security bridges for communications between containers. The system also provides for communications from one container to a legacy network/device or from a legacy network/device to another legacy or any other network or communicating device, whether networked or not. Dynamic Encryption Technology eliminates vulnerabilities caused by exposure of any single encryption key by continuously changing encryption keys and keeping the keys synchronized in a fault-tolerant manner.
Perpetual Authentication Technology uses multiple virtual channels or tunnels for encryption so that in the event one channel or tunnel is compromised, the other tunnels maintain encryption integrity. Together, these technologies not only eliminate the single point of failure problem created by having keys exposed through brute force, side channel, or other types of attack, but do so with very low latency and performance overhead. Whether at rest or in-motion, the encryption processes described ensures communications data (and all associated signals) remains safe, secure and uncompromised.
Up to this point, unmanageable encryption overhead has prompted developers to transfer encryption responsibilities to business operations, ultimately inflating costs.
The present disclosure and associated invention provides technology that abstracts container services into a Trustplane. The Trustplane secures data in transit simply and reliably, allowing developers to ensure data integrity without concern for Data Plane and Control Plane configurations or security vulnerabilities. With applications running in natively-secured ICEMicro containers, VPNs are no longer the vulnerable and expensive chokepoint that limits multi-environment deployments.
No known software container security systems, however, exist that will perform the use of singularly or in combination hidden dynamic random access devices with an encryption system utilizing selectable keys and key locators for communications using randomized encrypted data together with sub-channels and executable coded encryption keys.
As it is known in cryptology, encryption techniques (codification) using standard and evolving algorithms are used so that data exposed to undesirable third parties are encrypted making it difficult (and intended to be impossible) for an unauthorized third party to see or use it. Usually, for encryption, the term ‘plaintext’ refers to a text which has not been coded or encrypted. In most cases the plaintext is usually directly readable, and the terms ‘cipher-text’ or ‘encrypted text’ are used to refer to text that has been coded or “encrypted”. Encryption experts also assert that, despite the name, “plaintext”, the word is also synonymous with textual data and binary data, both in data file and computer file form. The term “plaintext” also refers to serial data transferred, for example, from a communication system such as a satellite, telephone or electronic mail system. Terms such as ‘encryption’ and ‘enciphering’, ‘encrypted’ and ‘ciphered’, ‘encrypting device’ and ‘ciphering device’, ‘decrypting device’ and ‘decipher device’ have an equivalent meaning within cryptology and are herein used to describe devices and methods that include encryption and decryption techniques.
There is an increasing need for security in communications over public and private networks. The expanding popularity of the Internet, and especially the World Wide Web, have lured many more people and businesses into the realm of network communications. There has been a concomitant rapid growth in the transmission of confidential information over these networks. As a consequence, there is a critical need for improved approaches to ensuring the confidentiality of private information and especially for software containers.
Network security is a burgeoning field. There are well known encryption algorithms, authentication techniques and integrity checking mechanisms which serve as the foundation for today's secure communications. For example, public key encryption techniques using RSA and Diffie-Hellman are widely used. Well known public key encryption techniques generally described in the following U.S. Pat. No. 4,200,770 entitled, Cryptographic Apparatus and Method, invented by Hellman, Diffie and Merkle; U.S. Pat. No. 4,218,582 entitled, Public Key Cryptographic Apparatus and Method, invented by Hellman and Merkle; U.S. Pat. No. 4,405,829 entitled Cryptographic Communications System and Method, invented by Rivest, Shamir and Adleman; and U.S. Pat. No. 4,424,414 entitled, Exponentiation Cryptographic Apparatus and Method, invented by Hellman and Pohlig. For a general discussion of network security, refer to Network and Internetwork Security, by William Stallings, Prentice Hall, Inc., 1995.
In spite of the great strides that have been made in network security, there still is a need for further improvement. For example, with the proliferation of heterogeneous network environments in which different host computers use different operating system platforms, there is an increasing need for a security mechanism that is platform independent. Moreover, with the increasing sophistication and variety of application programs that seek access to a wide range of information over networks, there is an increasing need for a security mechanism that can work with many different types of applications that request a wide variety of different types of information from a wide variety of different types of server applications. Furthermore, as security becomes more important and the volume of confidential network transactions expands, it becomes increasingly important to ensure that security can be achieved efficiently, with minimal time and effort.
The creation of proprietary digital information is arguably the most valuable intellectual asset developed, shared, and traded among individuals, businesses, institutions, and countries today. This information is mostly defined in electronic digital formats, e.g., alphanumeric, audio, video, photographic, scanned image, etc. It is well known that a large number of encryption schemes have been used for at least the last 100 years and deployed more frequently since the onset of World Wars I and II. Since the beginning of the cold war, the “cat and mouse” spy missions have further promulgated the need for secure encryption devices and associated systems.
Simultaneously, there has been an increased need for mobility of transmissions including data and signals by physical or logical transport between home and office, or from office to office(s) among designated recipients. The dramatic increase in the velocity of business transactions and the fusion of business, home, and travel environments has accelerated sharing of this proprietary commercial, government, and military digital information. To facilitate sharing and mobility, large amounts of valuable information may be stored on a variety of portable storage devices (e.g., memory cards, memory sticks, flash drives, optical and hard disc magnetic media) and moved among home and office PCs, portable laptops, PDAs and cell phones, and data and video players and recorders. The physical mobility of these storage devices makes them vulnerable to theft, capture, loss, and possible misuse. Indeed, the storage capacity of such portable storage devices is now approaching a terabyte, sufficient to capture an entire computer operating environment and associated data. This would permit copying a targeted computer on the storage media and replicating the entire data environment on an unauthorized “virgin” computer or host device.
Another trend in data mobility is to upload and download data on demand over a network, so that the most recent version of the data is always accessible and can be shared only with authorized users. This facilitates the use of “thin client” software and minimizes the cost of storing replicated versions of the data, facilitates the implementation of a common backup and long-term storage retention and/or purging plan, and may provide enhanced visibility and auditing as to who accessed the data and the time of access, as may be required for regulatory compliance. However, thin client software greatly increases the vulnerability of such data to hackers who are able to penetrate the firewalls and other mechanisms, unless the data is encrypted on the storage medium in such a way that only authorized users could make sense of it, even if an unauthorized user were able to access the encrypted files.
There is a balance among legal, economic, national security, and pragmatic motivations to develop robust security implementations and policies to protect the storage of proprietary digital information, based on the value of the information, the consequences of its exposure or theft, and the identification and trust associated with each of the targeted recipients. In order to provide such varying degrees of protection for portable storage devices, system methods and application functionality must be developed and easily integrated into the operating procedures of the relevant institutions. Different policies defining degrees of protection are required to economically accommodate and adapt to a wide range of targeted recipient audiences for this data.
Known encryption systems for these devices include the “Data Encryption Standard” (“DES”), which was initially standardized by the “American National Bureau of Standards”, currently “National Institute of Standards and Technology” (“NBS” or “NIST”) in the United States. Another includes the “Fast data encipherment algorithm FEAL” (FEAL) developed later in Japan, and described in the IECEJ Technical Report IT 86-33. U.S. Pat. No. 5,214,703 entitled “Device for the Conversion of a Digital Block and Use of Same” describes the use of additional devices as does an encryption device described in U.S. Pat. No. 5,675,653 entitled “Method and Apparatus for Digital Encryption”. In most cases, the user making use of protecting the data after encryption or enciphering of a plaintext has delegated the strength of the invulnerability of the encryption to be positioned in front of an enemy attack. This positioning is aimed to discover the contents of the cipher text or the encryption key used, trusting in the organizations, institutions, or experts endorsing their security and providing a degree of confusion and diffusion of values introduced by the encryption device used in the cipher text. The user encrypting a particular plaintext has no objective security regarding the degree of confusion and diffusion of values present in a cipher text that result from the application of the encryption device. Attacks on personal computers and commercial, government and military data are now commonplace; indeed, identity theft of passwords is the largest white-collar crime in the United States. Yet passwords and PINs (Personal Identification Numbers), in most cases generated by human beings who are tempted to use native-language words, Social Security Numbers, telephone numbers, etc., are still the most used access security methods for protecting portable encryption devices, and among the most vulnerable to both brute force dictionary attacks as well as sophisticated logic tracing. Professional criminal attackers and even amateur hackers now have access to sophisticated software and supercomputing networks that can unknowingly invade processing devices and storage devices, trace software instruction sequences and memory locations, and by knowing or discovering the algorithms being used, intercept and copy encryption keys, PINs, and other profile data used to protect the access to stored content. They can exploit vulnerabilities in the underlying commercial software, or in the construction of the integrated circuit chips housing and executing the cryptographic processes, or in the specialized cryptographic software, which enables exposing keys and access parameters at some deterministic point in the processing sequence. Industrial laboratory facilities are also available to read the data content stored in memory cells by measuring the electronic charge through the use of electronic beam microscopes, and thus steal stored PINs, keys, and therefore access the previously protected data.
Many prior methods exist for the key management protection necessary for securing key encryption keys for large groups of users. Split-key secret sharing schemes have been proposed whereby the decryption key is split and shared among multiple parties or entities to be combined to reconstitute the decryption key. In these cases, however, the individual secret shares themselves are maintained statically in multiple storage devices, generally on-line, where they are susceptible to attackers, particularly from within the institution, who can target the secret shares and recombine then to form the decryption key. Such solutions are often implemented for relatively static configurations of computing and storage devices and related communities of interest or tiers of users, and have not addressed the ability to so protect key encrypting keys when the data itself, and the means to encrypt and decrypt the data and to generate and recombine the shared secrets, are on a portable device.
Current file encryption systems provide a technique for a general-purpose computer to encrypt or decrypt computer-based files. Current encryption and decryption techniques typically rely on lengthy strings (e.g., 1024 bits, 2048 bits, 4096 bits, or more) to provide for secure encryption or decryption of files. Computer performance suffers due to the amount of data in the messages as well as the size of the encryption keys themselves.
Asymmetric file encryption systems use a different key to encrypt a file from the key used to decrypt the encrypted file. Many current file encryption systems rely on asymmetric encryption, such as those that rely on public key/private key pairs. An example of an encryption algorithm that utilizes public key/private key pairs is the RSA (Rivest, Shamir, and Adleman) algorithm. Symmetric file systems use an identical key to encrypt a file as the key used to decrypt the encrypted file. Certain file encryption systems utilize a cryptographic process or random number generator to derive a random symmetric key known as the file encryption key (FEK). The FEK is used to encrypt the file. Symmetric cryptography functions up to five orders of magnitude faster than asymmetric cryptography on files. Even with a very fast key device or software that encrypts/decrypts using the asymmetric key, any such file encryption system still has to overcome the fact that asymmetric keys generally operate at orders of magnitude slower than symmetric keys. When using the file encryption key, each time a file is being authenticated, the file encryption key has to be decrypted by the asymmetric key which is time consuming, but becoming less so as computer speeds and operations are constantly improving.
What is needed are highly robust and proven security techniques incorporated into new system methods and into new commercially available portable storage hardware apparatus to implement configurable security policies for accessing information through rigorous authentication means, to secure the information with certified levels of accepted cryptographic technology, and to rigorously control the environment within which the information is shared.
In addition, there is a need to better secure portable storage apparatus and method of encrypting and sealing digital information files and storing them in the device's integral or removable memory, or alternatively on the host device's memory or other ancillary memory storage devices, while operating under cryptographically protected security policies for transport and authorized access to such digital information.
There is also a need for secure physical and logical transport of data to and from multiple recipients. To this end, it is desirable to provide a means of securely transporting data from one place to another, if the user has to carry the data or physically transport the data and the secure encryption device, and somehow communicate the information necessary to log on and access the data by another authorized user. What is required are a multiplicity of methods to securely transport the encrypted data, either physically or logically, between an Originator user and one or more Receivers.
The use of encryption devices by the general population is becoming very common in for example, commercial electronic transactions and/or electronic mail. A predominant portion of all societies want to believe in an objective, easily verified way, that the maximum degree of the diffusion and confusion (encryption) of data and data values provided by a system they are using to encrypt their data, is the superior set of encrypted devices and system.
The present disclosure relates generally to a cryptographic management scheme that provides for network security, mobile security, and specifically and more particularly relates to devices (such as containers) and a system for creating and manipulating encryption keys without risking the security of the key. The present disclosure addresses all of the needs described directly herein, as well as described earlier above.